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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI). 
The present document is part 6 of a multi-part deliverable. Full details of the entire series can be found in part 1 [2]. 
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Scope 



The present document contains service-specific details for the handover of the lawfully intercepted PSTN/ISDN 
Services (including emulated services such as those defined in ES 282 002 [3]) using packet-based techniques as 
defined in TS 102 232-1 [2]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 101 671: "Lawful Interception (LI); Handover interface for the lawful interception of 

telecommunications traffic". 

NOTE: Periodically TS 101 671 is published as ES 201 671. A reference to the latest version of the TS as above 
reflects the latest stable content from ETSI/TC LI. 

[2] ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific Details 

(SSD) for IP delivery; Part 1: Handover specification for IP delivery". 

[3] ETSI ES 282 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional 
architecture". 

[4] ITU-T Recommendation X.680: "Information technology - Abstract Syntax Notation One 

(ASN.l): Specification of basic notation". 

[5] Void. 

[6] ITU-T Recommendation G.711 (1988): "Pulse code modulation (PCM) of voice frequencies". 

[7] IETF RFC 4566: "SDP: Session Description Protocol". 
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[8] 

[9] 
[10] 



ETSI TS 187 005: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); NGN Lawful Interception; Lawful interception functional 
entities, information flow and reference points". 

Void. 

IETF RFC 3551: "RTF Profile for Audio and Video Conferences with Minimal Control". 



2.2 



Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 



[i.l] 
[i.2] 



ETSI TR 102 053: "Telecommunications security; Lawful Interception (LI); Notes on ISDN 
lawfull interception functionality" . 

ETSI TR 102 503: "Lawful Interception (LI); ASN.l Object Identifiers in Lawful Interception 
Specifications". 



3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the terms and definitions given in TS 102 232-1 [2] and TS 101 671 [1] 
apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ASN.l 
CC 
CIN 
CSP 



Abstract Syntax Notation One 
Content of Communication 
Communications Identity Number 
Communications Service Provider 



NOTE: CSP covers all Access Providers, Network Operators and Service Providers. 

HIl Handover Interface 1 (for Administrative Information) 

HI2 Handover Interface 2 (for Intercept Related Information) 

HI3 Handover Interface 3 (for Content of Communication) 

IP Internet Protocol 

IRI Intercept Related Information 

ISDN Integrated Services Digital Network 

LEA Law Enforcement Agency 

LEMF Law Enforcement Monitoring Facility 

LI Lawful Interception 

MF Mediation Function (at CSP) 

PDU Protocol Data Unit 

PES PSTN/ISDN Emulation Subsystem 

PSTN PubUc Switched Telephone Network 

RTP Real-time Transport Protocol 

SDP Session Description Protocol 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

UDP User Datagram Protocol 
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General 



4.1 Approach 

The present document forms part 6 of the TS 102 232 family of standards, in that it is a service-specific component of 
the TS 102 232-1 [2] framework. 

For ISDN interception TS 101 671 [1] defines the interception behaviour that leads to visible IRI events on the 
handover interface. TR 102 053 [i.l] provides detailed guidance in support of TS 101 671 [1]. 

The present document provides a model for handover that may be used in conjunction with the interception domain 
specification TS 187 005 [8]. TS 187 005 [8] also provides an overview of the document structure within the NGN LI 
domain. 



4.2 



Reference model 




Network Mediation 
Function (MF) 



Law Enforcement 

Monitoring 
Facility (LEMF) 



Handover 
interface 



Figure 1 : Reference model 



Headers, data exchange and networks 



5.1 Approach 



TS 102 232-1 [2] describes a technique for data exchange, and specifies the headers that shall be associated with the 
results of interception. The present document follows TS 102 232-1 [2] regarding headers, data exchange and networks. 



5.2 



Structures 



IRI events from TS 101 671 [1] are sent using the structure ETSI671IRI. Supplementary information IRI (defined in 
clause 6.3) is sent using either the structure pstnlsdnlRI or the structure pstnlsdnCC (see clause A.2). CC is sent using 
the structure pstnlsdnCC (see clauses 6.2 and A. 3). 



5.3 



Definition of a communications session 



A new Communications Identity Number (or CIN) is assigned each time a new communications session begins. See 
TS 101 671 [1] for the definition of communications session. 

Typically, a new communications session is defined to begin (i.e. a new CIN is assigned) when each IRI-BEGIN 
message is sent (as listed in TS 101 671 [1]), then all further IRI and CC relating to that session has the same CIN. 
Typically, a REPORT record would form a communications session in its own right. If CC or an IRI record is generated 
for a session before the IRI-BEGIN is sent (e.g. through fault situations, or owing to unexpected latency), the CSP shall 
still ensure that all IRI and CC in the communication session has the same CIN. 
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6 Intercept Related Information (IRI) and Content of 

Communication (CC) 

6.1 Definition of IRI events and CC events 

IRI events are defined as per TS 101 671 [1]. CC is sent on all occasions that CC would be sent under TS 101 671 [1]. 
Further details for ISDN are provided by the state model and message sequence diagrams in TR 102 053 [i.l]; in 
particular see clause 6 of TR 102 053 [i.l]. 

6.2 CC format 

CC shall be expressed as an RTF frame. The CC shall also contain the RTF header, UDF header and IF header, except 
by agreement between CSF and LEA. 

NOTE: CSFs and LEAs may choose to omit headers because they are unavailable at the point of interception. 

The Supplementarylnfo FrameType field indicates which headers are present in a given CC stream. If all headers are 
present, the FrameType field may be omitted. 

In the case where the RTF header is unavailable, one may be inserted by the mediation function, subject to agreement 
between LEA and CSF. The addition of an inserted RTF header may aid processing the audio stream at the receiver. 

The content (i.e. RTF payload) shall be a complete, unmodified copy of CC information that is part of the target 
communication. 

The RTF header shall accurately describe the target communication. 

The information contained in the IF and UDF header does not necessarily relate to any media flow as seen by the target. 

IF and UDF headers shall not be inserted to the intercepted material by the mediation function if they are unavailable. 

If encryption has been applied within the CSF's domain and under their control, either it shall be removed or full details 
of the encryption including keys shall be supplied. 

Typically under FSTN/ISDN the codec used is ITU-T Recommendation G.71 1 [6]. The codec in use shall be signalled 
as described in clause 6.3. 

6.3 Supplementary information 

6.3.1 Requirements for supplementary information 

It is required that the LEA has enough information to decode and comprehend the traffic delivered over the Handover 
Interface. The following information is required: 

• Description of the format of the CC, to allow the LEMF to understand the information within the CC. 
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6.3.2 Supplementary information 

Supplementary information is defined to be the following set of information. 



Field name 


Status 


ASN.1 field 


Information 


Media format 


IVIandatory 


mediaFormat 


This field signals the codec used, as defined in 
RFC 3551 [10]. The supplementary info shall contain only 
one media format (send another supplementary 
information messages if the format changes). 


IVIedia attributes 


Conditional 
(i.e. mandatory 
under the 
conditions 
listed) 


mediaAttributes 


If any extra information (beyond the IVIedia Format) is 
needed to understand the delivered CC then it shall be 
sent here, in the format defined in the a= field of SDP (see 
RFC 4566 [7]). Typically, media attributes shall be present 
if and only if the media format is 32 or above. 


Encryption l<ey 


Conditional 


encryptionKey 


See clause 6.2. 


Session name 


Optional 


sessionName 


If present in the target communication (e.g. SDP 's=' field), 
it may be present in supplementary information as decided 
by national agreement. 


Session 
information 


Optional 


sessionlnfo 


If present in the target communication (e.g. SDP 'i=' field), 
it may be present in the target communication, it may be 
present as decided by national agreement. 


Copy of SDP 
message 


Optional 


copyOf S D PMessage 


In addition to the above information, an SDP message may 
be included here. 



6.3.3 Sending supplementary information 



Supplementary information shall be sent as soon as possible for a communications session, and should be sent before 
CC is available. 

If supplementary information is not available before the CC, under no circumstances shall CC be buffered or delayed. If 
supplementary information is critical to interpreting the CC, then CSPs shall ensure their systems are designed to avoid 
any delay in sending supplementary information. 

If the communications session contains traffic in more than one direction, then one set of supplementary information 
shall be sent for each direction present. Under some circumstances, the traffic sent in one direction will have a different 
set of supplementary information from traffic sent in the other direction (e.g. traffic to the target uses a different codec 
compared to traffic going from the target). Under these circumstances, the direction flag shall always be present and 
correct for all CC PDUs, and only the values 'To Target' and 'From Target' shall be used. 

If the supplementary information changes during a session (e.g. change of codec) then a new set of supplementary 
information shall be sent as soon as possible (it should be sent before the change occurs). It is required that the LEMF 
can identify the point in the CC stream at which the change took place. If it is not clear from the CC, then the CSP 
should populate the field 'First PDU number' within the structure 'InformationAppliesTo', to state the sequence number 
of the first CC-PDU to which the new supplementary information applies. 

Supplementary information shall be sent either as IRI or in CC-PDUs (in this case at least in the first PDU and in the 
following PDUs only if there are any changes during the session). 

6.3.4 Identification of CCLinks 

TS 101 671 [1] identifies certain occasions when different CCLinks are established (e.g. multi-party calls). 

If there are a number of different CCLinks (see TS 101 671 [1]), then one set of supplementary information shall be 
sent for each CC Link and the CCLinkID represent the CCLink that this information applies to. Within each CC Link, 
traffic in different directions shall be isolated and identified as described in clause 6.3.3. 

Note that the sequence numbering of CC-PDUs is not affected by the CCLink counter (i.e. do not maintain separate 
sequence number counts for separate CCLinks). 
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Annex A (normative): 
ASN.1 forlRlandCC 

A.1 Note on integrating ASN.1 structures 

IRI information structures are defined by the ASN.1 in TS 101 671 [1]. The headers that shall be applied to all IRI are 
defined in TS 102 232-1 [2]. There is some overlap between these structures, in that some fields which are present in 
TS 101 671 [1] IRl-Parameters are then repeated in the TS 102 232 PSHeader construction. In particular, there are the 
following overlaps: Lawful Intercept Identifier, Communication Identifier, TimeStamp. 

The present document follows TS 102 232-1 [2] for header information and requires that the TS 102 232 header shall be 
populated. For ease of interoperability the present document recommends that repeated fields should be populated in 
both the TS 102 232 and TS 101 671 [1] parts of the header. 



A.2 ASN.1 definitions 

The ASN.1 definitions are contained in a .txt file (PstnlsdnPDU, ver3.txt contained in archive 
ts_10223206v020301p0.zip) which accompanies the present document. 

The ASN.1 (ITU-T Recommendation X.680 [4]) module that represents the information in the present document and 
meets all stated requirements is shown below. TR 102 503 [i.2] gives an overview of the relevant Object Identifiers 
(OID) used in ASN.1 modules of the Lawful Intercept specifications and points to the specification where the modules 
can be found. 



-- Description of the Pstnlsdn PDU 

PstnlsdnPDU 

{itu-t{0) identif ied-organization (4) etsi{0) securityOomain (2) lawfullntercept (2) li-ps{5) 
pstnlsdn{6) versions (3)} 

DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 

IMPORTS 

-- from TS 101 671 [1] 
IPAddress 

FROM HI20perations 

{itu-t{0) identif ied-organization (4) etsi{0) securityDomain (2) lawfullntercept (2) hi2{l) 
versionlO (10) } 

-- from TS 102 232-01 [2] 
PayloadDirection 

FROM LI -PS -PDU 

{itu-t{0) identif ied-organization (4) etsi{0) securityDomain (2) lawfullntercept (2) li-ps{5) 
genHeaderd) versions (8) } ; 



Object Identifier Definition 



-- definitions are relative to 

-- {itu-t{0) identif ied-organization (4) etsi{0) securityDomain (2) lawfullntercept (2) 

pstnlsdnlRIObjId RELATIVE-OID ::= {li-ps(5) pstnlsdn{6) version3{3) iRI{l)} 

pstnlsdnCCObjId RELATIVE-OID ::= {li-ps{5) pstnlsdn{6) version3{3) cC{2)} 
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-- Description of the Pstnlsdn IRI 



PstnlsdnlRI ::= SEQUENCE 






pstnlsdnlRIObjId 


[0] 


RELATIVE-OID 




pstnlsdnlRIContents 


[1] 


PstnlsdnlRIContents 


PstnlsdnlRIContents ::= CHOICE 






supplementary-Info 


[0] 


Supplementaryinf o , 


Supplementary-Info 


:= SEQUENCE 




informationAppliesTo 


[0] 


InformationAppliesTo, 


-- Identifies the PDUs 


to which this 


info applies 


mediaFormat 


[1] 


INTEGER {0. .127) , 


--As defined in 


RFC 3551 [10] 




medlaAt tributes 


[2] 


OCTET STRING 


OPTIONAL, 


-- Format as per 


RFC 4566 [7] 




-- Clause 6.3 describes 


when the mediaAttributes shall be present 


encrypt lonKey 


[3] 


OCTET STRING 


OPTIONAL, 


-- Format as per 


RFC 4566 [7] 




sessionName 


[4] 


OCTET STRING 


OPTIONAL, 


-- Format as per 


RFC 4566 [7] 




sessionlnfo 


[5] 


OCTET STRING 


OPTIONAL, 


-- Format as per 


RFC 4566 [7] 




copyOfSDPMessage 


[6] 


OCTET STRING 


OPTIONAL, 


-- Format as per 


RFC 4566 [7] 




frameType 


[7] 


FrameType OPTIONAL 


-- Populated if one or more protocol 


layers are missing from CC data 


-- May be omitted if all headers are 
} 


present . 



InformationAppliesTo ::= SEQUENCE 

-- Identifies the PDUs to which a piece of supplementary information applies 

{ 

payloadoirection [0] PayloadDirection, 

-- The direction of the traffic to which this info applies 
cCLinkID [1] INTEGER {0.. 65535) OPTIONAL, 

-- If there are multiple CCLinks, this field states CCLink to which this info applies 
firstPDUNumber [2] INTEGER { .. 4294967295 ) OPTIONAL, 

-- The supplementary info applies to all PDUs with this sequence number and above 



FrameType 

{ 



ENUMERATED 



ipFrame (0) , 

-- All headers are present 
udpFrame { 1 ) , 

-- IP header is missing 
rtpFrame (2) , 

-- UDP and IP headers are missing 
audioFrame { 3 ) , 

-- All headers are missing 
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-- Description of the Pstnlsdn CC 



PstnlsdnCC : := 

r 


SEQUENCE 












1 


pstnlsdnCCObjId 




[0] 


RELATIVE 


-OID, 










pstnlsdnCCContents 


[1] 


OCTET STRING, 










-- See clause 6.2 for definition 


of format 


of Pstnlsdn 


CC 






cCLinkID 




[2] 


INTEGER 


{0. .65535) 


OPTIONAL, 








-- Shall be 


present 


if 


multiple 


CCLinks are used {see clause 


6.3.4) 




supplementaryin 


Eo 


[3] 


Supplement arylnfo 


OPTIONAL 






} 


-- Shall be 


present 


at 


least in 


the first 


PDU 







end of PstnlsdnPDU 
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Annex B (informative): 
Change request history 



status of TS 102 232-6 
Service-specific details for PSTN/ISDN services; hHandover specification for IP delivery 


Date 


Version 


Remarks 


September 2006 


2.1.1 


First publication of the TS after approval by ETSI/TC Lll#13 (6-8 September 2006, 
Stockholm) 

Version 2.1 .1 prepared by rapporteur Mark Shepherd (HO UK) 


April 2007 


2.2.1 


Included Change Request: 

TS102232-06CR001r1 (cat B) on Clarification of use of RTP/UDP/IP headers 

This CR was approved by TC Ll#1 5 (23-25 April 2007; Riga) 

Version 2.2.1 prepared by Peter van der Arend (Chairman TC LI) 


May 2008 


2.3.1 


Included Change Requests: 

TS102232-06CR002r1 (cat C) on Some comment and modification on the identification 

CCLinks defined in the clause 6.3.4 

This CR was approved by TC Ll#16 (2-4 October 2007; Berlin) 

TS102232-06CR003r1 (cat B) on Supplemetarylnfo in PstnlsdnCC 
This CR was approved by TC Ll#18 (27-29 May 2008; Chania) 

Version 2.3.1 prepared by Peter van der Arend (Chairman TC LI) 


Rapporteur of this Teclinicai Specification is Marl< Sheplierd 
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History 



Document history 


V2.1.1 


December 2006 


Publication 


V2.2.1 


May 2007 


Publication 


V2.3.1 


August 2008 


Publication 
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